Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/idpr/idpr-minutes-93mar.txt

Text File | 1993-05-12 | 6.5 KB | 160 lines

CURRENT_MEETING_REPORT_


Reported by Martha Steenstrup/BBN

Minutes of the Inter-Domain Policy Routing Working Group (IDPR)

The IDPR Working Group met for two consecutive sessions during the March
1993 IETF meeting.  We discussed the status of IDPR as a standard as
well as experimental work that we are currently pursuing.

Two new IDPR Internet-Drafts were issued prior to the IETF meeting:


  1. An updated version of the IDPR MIB, written by Woody Woodburn of
     Sparta.
  2. A discussion of the DNS modifications to support IP address to
     administrative domain mappings, written by Rob Austein of Epilogue.


If you have not yet obtained a copy of these new Internet-Drafts, you
are encouraged to do so.  Please send all comments on the drafts to
[e-mail].

Internet Pilot Demonstration

The Internet pilot demonstration of IDPR is proceeding.  We will
demonstrate the functioning of IDPR in the presence of policies
(``acceptable use policies'') supplied by the transit networks NSFnet,
NSInet, and TWBnet.  No routers in any of these networks will actually
run IDPR. Rather, special IDPR routers (``policy gateways'' in the IDPR
terminology) will act on behalf of NSFnet, NSInet, and TWBnet to supply
policy routing.  These policy gateways will only handle traffic
designated as IDPR traffic.  IDPR traffic will be generated by a small
set of hosts at BBN, SRI, UCL, and ISI; no other Internet hosts will
generate IDPR traffic.

Policy gateways will be located at BBN, SRI, UCL, and ISI and will act
on behalf of these sites to handle IDPR traffic.  Policy gateways will
also be located at the FIXes and will act on behalf of NSFnet, NSInet,
and TWBnet to handle IDPR traffic.  There will be two SPARCstations
installed at the FIXes, one SPARCstation per FIX Ethernet.  Each
SPARCstation will act as a set of three policy gateways, one policy
gateway per participating transit network per FIX.

We will show that:


   o IDPR selects routes that respect the access restrictions imposed by
     the transit networks and the service requirements (for example, low
     delay) of the sources.

   o One may reconfigure transit network policies to suit current needs,

                                   1





     and IDPR routes will reflect these changes.

   o IDPR is robust in the presence of connectivity failures and quickly
     learns new routes.

   o If a source attempts to setup a route that violates transit network
     access restrictions, the transit network refuses the route.


The policy gateways handle IDPR traffic only and will not touch other
traffic.  Hence, this pilot demonstration will not affect regular
(non-IDPR) traffic traveling over the FIXes or over any of the transit
networks attached to them.

Two years ago, we demonstrated this functionality in networks such as
DARTnet; this will be the first demonstration of IDPR functionality in
the general Internet.

Two of the more ``experimental'' topics we discussed included adding the
super domain functionality, described in the IDPR architecture, to the
IDPR protocols and integrating resource reservation with IDPR.

To handle hierarchies of domains, IDPR must have a way to represent
hierarchical domain addresses and to define the distribution scope of
routing information in the hierarchy.  Routing information from a given
domain may be visible at multiple levels within the hierarchy if the
distribution scope for that domain includes multiple levels.

We define the ``routing context'' as the level in the domain hierarchy
at which the routing will occur.  For example, suppose domain A contains
domain B which in turn contains a set of domains C1,...,Cn.
Furthermore, suppose we want to route among the C domains.  Then the
routing context is represented as A/B. Thus, when we refer to Ci after
defining the routing context, it is clear that we mean Ci contained in B
contained in A, rather than Ci contained in some other domain Y. Routing
context must be distributed in routing information messages as well as
in path setup messages, to identify the context of the information
contained within the message.

When integrating resource reservation and IDPR, there must exist
mechanisms to generate routes that are likely to have the requested
resources, to reserve resources, and to control traffic such that
reservations are honored.  IDPR relies on intra-domain mechanisms to
that support resource reservation and traffic control across a domain,
and hence there must exist an interface for communicating reservation
information to the intra-domain resource reservation mechanism.

IDPR domains supporting resource reservations should distribute the mean
and standard deviation of the bandwidth available for reservation
between relevant virtual gateway pairs, in their routing information
messages.  Route servers can select routes based on the mean values of
available bandwidth or even on more pessimistic views such as available
bandwidth equal to n standard deviations lower than the mean.

                                   2





Generating routes with such bandwidth metrics should increase the
chances of producing routes that can in fact provide the requested
bandwidth.

Using statistical measures of available bandwidth, a domain need not
generate a routing information message for each resource reservation or
release.  Thus, we can contain the amount of routing information
messages.  However, when bandwidth available for reservation is almost
exhausted, a domain should immediately generate a routing information
indicating this state.  This will prevent generation of new paths
through this domain.  Moreover, when the available bandwidth increases
to a reasonable amount again, the domain should generate a routing
information message to inform other domains that it has sufficient
resources to accept more traffic.  We have simulated such algorithms,
but have not yet implemented them in an actual network.

Attendees

Robert Austein           [e-mail]
David Bridgham           [e-mail]
Al Costanzo              [e-mail]
Shane Dawalt             [e-mail]
Chip Elliott             [e-mail]
Frank Hoffmann           [e-mail]
Frank Kastenholz         [e-mail]
Tony Li                  [e-mail]
Charles Lynn             [e-mail]
Glenn Mackintosh         [e-mail]
Brad Passwaters          [e-mail]
Manoel Rodrigues         [e-mail]
Shawn Routhier           [e-mail]
William Simpson          [e-mail]
Martha Steenstrup        [e-mail]
Stuart Stubblebine       [e-mail]



                                   3